On 30 Sep 07, at 12:41 AM 30 Sep 07, Stephane Nicoll wrote:
On 9/29/07, Jason van Zyl <[EMAIL PROTECTED]> wrote:
Why, and says who? These things are not cast in stone and we have the
ability to adapt the process to make it more productive.
[...]
I don't really care. Staging a release is not a big deal, just
invariably pointless for an alpha because 99% of the time no one will
actually do anything with the staged copy. It's more important that
the stuff gets cranked out for feedback so it can be fixed. I mean
even with releases hardly anyone looks. It's nice idea in theory but
if it serves no practical purpose what is the point. I was hopeful
that the staged copy would illicit feedback but doesn't seem to have.
Not much anyway.
I agree with you but, even if those things are not cast in stone, it's
commonly used. If we were to adapt for alphas, betas or anything else,
I think it makes more sense to discuss it a bit instead of doing it on
your side without telling anyone.
That's not the first time you're doing this and it's personally
confusing to me.
All I want is a mechanism that encourages more use in the
intermediary stages.
It takes more then a week to push out subsequent releases for an
alpha, the release plugin gets incrementally worse and has been
breaking things on subsequent releases itself because it's not tested
enough before pushing it out the door making the whole process more
painful. The staging plugin was never meant as a solution and it's
not all that great either.
We are a project which encourages the use of binaries and agile
development. We don't have an easy for people even to test in certain
cases. If you start with no local repository and repositories in your
settings activated by a profile with repositories it is unworkable.
For tools like Archetype where you start with no POM the settings
won't be used and there is no way to test it other then to give
someone an archive they have to unpack locally or they have to build
it themselves. Neither of these options are fantastic.
Between our release model taking so long, people historically not
looking at releases (which is normal people don't have a lot of spare
time to look at everything), our tooling not being quite up to snuff,
the staging plugin being a stopgap, and the release plugin breaking
things with subsequent releases (though Dan is working on the GPG
plugin I see) it becomes very hard to get these changes out to users
to utilize and provide feedback. If we don't make this easy, fast and
painless for users we lose them. A user having to wait 3 days to try
a bug fixed version of an alpha while a developer is focused on it is
painful. To be able to release it as it would be used in the wild is
the best way.
I have three very large clients who are very flexible in that they
would try alphas of certainly things in their lifecycle. But they
will not build from source, they will not introduce snapshot
repositories into their builds in order to consume changes. Build
from source is just not an option for a team who is suppose to be
consuming this technology. Using snapshot repositories is just too
unpredictable given the current mechanism, though I have tried to use
them in order to consume changes it's just not practical given the
instability so snapshots repositories have been ruled out.
The groups that I'm working with cannot be the only groups like this
in the world. If more alphas were produced it's very easy with a good
parent POM to change the version and attempt using an alpha in a
build. I would like to be able to crank out alphas as fast as humanly
possible so we stop losing this feedback. I want to make the alpha
process less painful for users so that more things are found so that
it is possible to have betas that have been suitably tested. This
simply is not the case with our plugins because we are missing
feedback during the entire span of time between releases.
I am pleading with you guys to help not make this process painful,
tied down with bureaucracy and get incremental changes out in a
usable form which Maven users are accustom to consuming. Building
from source and snapshot repositories are just too much to expect
from users who are simply trying to verify that issues have been
corrected. It is unfortunate that using snapshots it is not clear
what you are going to get but that's the situation we have right now
and I think we would do ourselves a great service to:
1) Reduce the time required to release alphas i.e. take three +1
votes and kick it out
2) Realize that people do not have a lot of time here and the process
of waiting 3 days is not adding much value because I would argue that
the second the vote goes up anyone really interested is going to look
at it very shortly
3) That in order for changes to be consumed by average users who are
willing to give us feed back it has to be easy to use these changes.
I would argue that no wait is required for alphas, but that for betas
and releases 3 days is not enough because people don't scrutinize
them enough. So this 3-day wait kills us from being agile in the
realm of alphas, and is way to short for a production release. This
doesn't happen because we can't get the feedback during alphas to
ensure that releases are production quality.
I want to enable our users to help us. We need less rigor in the
early incremental stages of new releases and more rigor when it comes
to production releases.
Cheers,
Stéphane
I only say this because I see very little, if any feed back on
release plugins, and even released versions of Maven. The best
feedback I get is from plugins that I just crank out from Mojo and I
get two or three people providing feedback and that really helps. I
mean even staging it sometimes doesn't help if you look at the last
release of Archetype. Releases must be scrutinized (even though they
aren't) but let the alphas sail out fast and furious for feedback. We
don't intermediary releases out fast enough because it still must be
a pain in the ass for people which means only the determined will
build from source which means we miss out on the vast majority of
potential feedback. People should lock down there plugin versions
(the enforcer plugin on the next release will help with that, and
they should turn off any automagic update policy) so that we can
release this stuff often and people can try it as they like.
We either adapt or people will continue annoy our users. People don't
release often because something is wrong in our process. It is still
deemed cumbersome because we still have the same pool of people doing
releases and not many new people. Three +1 votes should really mean
trying the software and actually reviewing code but we know that no
one does that so what is difference really between pointing at a
revision or trunk or putting some binaries somewhere?
--
Wendy
--------------------------------------------------------------------
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Thanks,
Jason
----------------------------------------------------------
Jason van Zyl
Founder, Apache Maven
jason at sonatype dot com
----------------------------------------------------------
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
--
Large Systems Suck: This rule is 100% transitive. If you build one,
you suck" -- S.Yegge
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Thanks,
Jason
----------------------------------------------------------
Jason van Zyl
Founder, Apache Maven
jason at sonatype dot com
----------------------------------------------------------
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
