ports/58260: New Port: print/lilypond-devel

[Patrick Atamaniuk]

Kris Kennaway(kris at obsecurity.org)@2003.11.16 13:40:23 +0000:
> On Sun, Nov 16, 2003 at 08:12:00PM +0100, Patrick Atamaniuk wrote:
> So you don't want anyone to commit it to FreeBSD?

On the contrary, i generally still want it to be committed.

As i have more urgent issues with print/lilypond (stable) itself, i decided
to leave the development version somewhere public available without
the need to constantly bug committers for now. 
I have a bad feeling writing a mail like `can anybody please look into 
that again?`, since i feel `for what did i file a pr if i have to ask 
once a month for review`. Personal thing. 
Applies for development/unstable ports only.

Since the development version is subject to more often changes, i fear
that the pr will be a huge list of followup diffs, soon. So i thought
portrookies could be good for me as long as i cannot update the port
myself. (Even if i could, portrookies would be still good)

But if print/lilypond-devel where imported, i (and the upstream authors) 
would gladly appreciate that in any case:)

> I think, he meant they are changed and freshest versions can be found on
> portrookies.

Right.
The PR is not complete, fixed some issues with configure for 4.9 REL.
It bulds fine on current, though.
Since for one no FreeBSD users use portrookies now (hope to change that with
good documentation becoming available) and on the other
hand committers may decide not to like portrookies, i'll continue filing
diffs on the PR whatever committers decide.
For Kris' very valid security reasons, i consider portrookies cvs
non-authoritative, anyways.

KK> >It's great to see enthusiasm for the new "portrookies" project, but at
Thanks. :)

> >the moment most committers are not using it
I hope that in the near future many committers start use this as 
a testbed, too.

TB> >I wonder what the view of "portrookies" is amongst the committers?

This i wonder, too, and so i simply started to use it for
  a) `unstable` ports for cutting-edge users,
     (where lilypond-devel is quite stable and tested on the upstream though)
  b) for stable ports which are completely hosed on FreeBSD cvs and where
     there is no feedback on questions. (Maybe i am impatient, but
     i'd like to throttle down user's questions about not being able
     to build and when they manage, how to un-break their info(1) dir files
	and how to pkg_delete with an out of date plist)
  Currently i am forced (for simplicity) to send the users a tar-file
  with a working version of the ports skeleton.

I hoped that a public version with web-cvs makes it easier to quick-check
for committers what i am doing. 80kb diffs in bz2.uu format are not really
usable for the short 'i'll take it' statement. :)

TB> >Is it a good thing? Will it help or hinder

After the commit-bit discussion (which i deliberately did not participate)
i decided for myself, that commit-bits must be earned through work and simply
started to play on portrookies. I welcome this new forum for there probably
will be more motivated newbies and experienced committers with the time to 
care about each others (trivial) problems. It is no problem there to 
learn the ropes, and bento will not break on commit mistakes.

Will it help or hinder? Mixed.
 On pkgsrc-wip i have the apprehension that if you don't bug NetBSD
committers enough, the wip-ports stay where they are and never make 
it into the tree. At least when there are only very few end-users 
reporting success. [No offence, NetBSD, lilypond pkgsrc is not 
completely finished/optimized there.]

imho Gnats will be required and very useful for new ports for quite a while.

Time will tell. It definitely is a nice testbed for maintainers without
commit-bit. At least for me i can satisfy my urge[:)] to produce usable
contributions. It helps to improve the quality of my PR's.
This, i think, is A Good Thing(tm).

The major advantage against gnats and ports@ list is, that i can make
quick fixes without making confusing PR's on PR's.
Furthermore, i face the problem, that my port changes on cvs (for valid
and good reasons) so my diffs fail to apply and i am not sure how to
follow up on that using gnats. patch on the patch? I (mis)decided to make
a complete new patchfile which fills up gnats and many mailboxes with
large uuencoded files. (Herewith i apologize in shame)

KK> >Dunno..I do have some security concerns about importing files from an
> >open CVS repository directly into FreeBSD.

Fully agreed. If portsrookies should live, there must be a policy/mechanism
to ensure ports integrity. Worstcase - sf 0wNeD - disqualifies a merge
from there. In all other cases, the port has to be verified somehow.
For one by the maintainer before announcing stability and secondly
by the committer as usual before mfr-ing (merge from rookies :)

OE> >One idea that popped up was downloadable shar files/diffs and to post
> >just the url to gnats, but hey, the project is one and a half day old...

i'd like checksummed/signed files/diffs ... :)

For my part i have the `original` port in my own cvs with one branch following
the official ncvs and the head with my changes. Head is posted on
public available service, using sf.net only for thoroughly pre-tested versions.
Despite all testing i have fixups as new issues arise, by users or by using the
port by myself.

I gladly use my local sources to diff against official ports for 
merging (say filing PR's), thus making portrookies a `documentation 
an testing only` tree for now.

Bottomline:
for the start i may humbly suggest, that maintainers may play with
portrookies, have there discussion and questions and test each others
stuff. Then, when they feel that the port reaches _good_ usability
(meaning does not break anything like `make index`, the upstream source is
ok, the sources are not trojaned and somewhat audited for security stuff,
the port actually builds, installs, does something more or less useful 
and deinstalls cleanly),
they then file a good old PR with a (again) tested patch / shar.

To motivate these maintainers, probably portsrookies-tested ports could
be seen with a (little) more appreciation than 'simple' new ports. ?

cheers,
 patrick


-- 
regards,
	Patrick Atamaniuk